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SECTION  I 


SURVEY  OF  COMPUTER  SIMULATIONS  OF  DIGITAL  AVIONIC  SYSTEMS 

1.0  INTRODUCTION 

This  report  describes  the  activities  and  results  of  tasks 
performed  by  Systems  and  Applied  Sciences  Corporation  in  conduct¬ 
ing  a  "Survey  of  Computer  Simulations  of  Digital  Avionic  Systems". 
The  report  is  organized  into  six  sections.  The  remainder  of  this 
section  provides  background  information  regarding  AFWAL/AAAS 
motives  for  initiating  the  survey.  The  survey  objectives  and  scope 
are  discussed  in  Section  II.  Section  III  addresses  the  survey 
strategy  and  approach  and  details  criteria  used  to  screen  candidate 
simulation  programs.  In  Section  IV,  survivors  of  the  screening  are 
presented  with  detailed  critiques  regarding  potential  AFWAL/AAAS 
applicability  accompanied  by  pertinent  design  and  descriptive  data. 
Included  are  assessments  in  terms  of  avionics  applicability  and 
accessibility  to  AFWAL/AAAS.  Section  V  presents  recommendations 
based  upon  the  survey  results.  Section  VI  is  a  compendium  of  simu 
lations  evaluated  during  the  survey.  A  bibliography  identifying 
pertinent  citations  and  articles  reviewed  during  the  survey  is  also 
included. 

1 . 1  BACKGROUND 

Within  the  simulation  community,  a  variety  of  simulation 
modeling  tools  have  been  developed  to  support  the  investigation 
of  systems  and  parameters  that  have  design  and  processing  charac¬ 
teristics  similar  to  avionic  systems.  Their  applications  include 
distributed  processing,  information  transfer,  and  fault  tolerance. 
Unlike  modeling  tools  of  the  past,  including  some  currently  being 
used,  these  systems  have  been  built  with  general  purpose  applica¬ 
tions  and  user  requirements  in  mind.  These  models  are  user-oriented 
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in  that  they  are  designed  with  libraries  of  sub-models  and  utilize 
methods  of  system  definition  intercommunication  and  interface 
techniques  that  reduce  time-consuming  set-up  and  run  times.  In 
short,  these  models  encourage  their  use  by  design  engineers. 
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SECTION  II 
SURVEY  GROUNDRULES 


2.0  OBJECTIVES 

The  Survey  of  Computer  Simulations  of  Digital  Avionic 
Systems  had  two  objectives.  The  primary  objective  was  to  identify 
state-of-the-art  simulation  techniques  and  models  with  digital 
avionics  simulation  applications .  The  resultant  models  must 
exhibit  capability  to  effectively  support  analysis  in  avionic 
network  design,  performance  or  cost.  They  must  further  possess 
design  features  and  characteristics  that  enhance  user  interface 
and  model/problem  definition. 

The  secondary  objective  was  to  provide  a  compendium  of 
recent  works  in  digital  simulation  that  involve  network  designs, 
distributed  processing,  etc.  The  compendium  would  provide  AFWAL 
with  an  awareness  of  current  efforts  and  centers  of  expertise 
within  the  simulation  community;  developers  and  users. 

2 . 1  SCOPE 

The  scope  of  the  survey  established  by  the  contract 
Statement  of  Work  required  SASC  to  consider  a  variety  of  simula¬ 
tions  and  models  independent  of  application  and  source. 

Simulation  is  being  used  as  an  analysis  tool  by  government, 
industry,  and  academic  organizations  for  a  variety  of  applications. 
This  fact,  combined  with  the  number  of  meetings,  journals,  and 
societies  concerned  with  the  various  aspects  of  simulation, 
represents  a  large  source  of  candidate  simulations. 

Direct  utility/use  of  a  simulation  to  AFWAL/AAAS  was  an 
important  aspect  of  the  survey.  Therefore,  constraints  were 
imposed  upon  the  selection  of  candidate  simulations.  Of  particular 
interest  to  AFWAL/AAAS  were  simulations  that  are: 
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1)  All  software:  All  modeling  and  simulation 
accomplished  by  software.  Hardware  limited 
to  user  interface  and  peripherals. 

2)  Compatible  with  available  computational 

resources:  i.e.,  DEC-10,  CDC  6600  computer, 

and  GASP  IV,  SIMSCRIPT,  or  FORTRAN  software. 

3)  Applicable  to  avionics  analysis  in  terms  of 
investigating  the  aspects  of  distributed 
processing,  information  transfers  and/or 
fault  tolerant  systems . 

4)  Operational  in  terms  of  status  and  validity. 

To  satisfy  the  primary  goal  of  the  survey  (identification 
of  design  tools  utilizable  by  AFWAL/AAAS)  the  above  constraints 
were  viewed  as  guidelines  rather  than  mandates.  Therefore, 
consideration  was  given  to  a  variety  of  simulations  that  did 
not  necessarily  satisfy  all  of  the  above  criteria. 
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SECTION  III 


SURVEY  APPROACH 


3 . 0  TASKS 

This  section  addresses  the  approach  and  methods  used  in 
performance  of  the  tasks.  It  includes  discussions  of  three 
principal  tasks  that  comprised  the  effort.  In  addition,  perti¬ 
nent  output  data,  along  with  screening  criteria  used  to  assess 
the  various  candidates,  is  identified.  The  discussions  of  the 
survey  tasks  are  presented  in  the  order  of  execution.  They  are: 

1.  Identification  of  Data  Sources 

2.  Data  Acquisition 

3.  Data  Analysis 

3.1  IDENTIFICATION  OF  DATA  SOURCES 

SASC's  first  task  was  to  develop  an  information  data 
base  that  included  preliminary  identification  of  candidate 
simulations  and  models  and  potential  sources.  This  data  base 
took  the  form  of  a  preliminary  Master  List  consisting  of  candi¬ 
date  simulations  that  grossly  exhibited  potential  avionics  and 
analysis  applicability.  This  preliminary  Master  List  was  the 
basis  for  later  activities,  and  was  modified  over  the  course  of 
the  study  to  include  only  the  best  information  available.  The 
Bibliography  of  this  report  contains  the  Master  List  in  its  final 
form.  Two  methods  were  used  to  identify  the  candidates.  They 
involved: 

1.  Automated  data  base  searches 

2.  Open  literature  searches 

Automated  data  base  searches  were  conducted  at  Wright- 
Patterson  Air  Force  Base  using  the  Defense  Documentation  Center 
(DDC) ,  and  Lockheed  Dialog  Service  (LDS)  data  base  retrieval 
systems.  A  strategy  was  derived  by  developing  key  word  descriptors 
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to  facilitate  each  search.  The  descriptors  were  derived  in  part 
from  the  requirements  specified  in  the  Statement  of  Work,  and 
from  items  and  areas  of  interest  pertinent  to  the  objective  of 
the  survey.  The  descriptors  used  included: 


Avionics 

Simulation 

Networks 

Time  Division  Multiplex 

Systems 

Models 

Distributed 

Architecture 


Information  Transfer 

Digital 

Computer 

Fault  Tolerance 

SIMSCRIPT 

GASP 

Q-GERT 

Processors 


Several  factors  required  that  the  search  process  be 
performed  repetitively.  This  was  necessary  because  of:  a)  the 
number  of  possible  combinations  of  search  terms,  b)  the  number 
and  types  of  topics  being  sought,  and  c)  the  possibility  that 
within  a  data  base,  similar  topics  could  conceivably  be  referenced 
using  different,  yet  similar,  terminologies  (for  example,  the 
terms  computer  and  processor,  or  simulation  and  model  are  often¬ 
times  used  synonymously) .  Indeed,  this  was  experienced  on  several 
occasions.  Therefore,  to  be  as  effective  as  possible,  it  was 
necessary  to  iterate  using  variations  on  the  descriptors. 

The  open  literature  search  was  conducted  concurrently 
with  the  DDC  and  LDS  searches.  Data  was  located  at  the  Air  Force 
Institute  of  Technology  Library,  the  Air  Force  Wright  Aeronautical 
Laboratory  library,  and  the  Wright  State  University  and  University 
of  Dayton  libraries.  The  approach  employed  was  based  upon 
scanning  pertinent  simulation  literature  journals,  scientific 
proceedings,  etc.,  and  to  record  pertinent  facts  relevant  to  the 
survey  objectives  for  future  reference. 

Documents  reviewed  during  the  open  literature  search 
were  from  a  variety  of  government  and  scientific  community  sources. 
Government  sources  included  the  National  Technical  Information 
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Service  (NTIS)  and  the  Scientific  and  Technical  Abstract  Reports 
(STAR).  Scientific  sources  were  both  academic  and  industrial: 
various  transactions  of  the  IEEE,  various  publications  of  ACM 
Special  Interest  Groups  (such  as  Simuletter) ,  non-af filiated 
journals  such  as  Computer  Networks ,  and  the  proceedings  of 
engineering  and  data  processing  conferences  and  symposia. 

Since  the  eligibility  of  the  candidates  was  based 
principally  on  the  inferences  of  titles  and  abstracts,  further 
screening  was  required.  To  facilitate  the  screening  process,  a 
set  of  screening  criteria  was  derived  and  descriptive  data 
regarding  each  candidate  acquired.  These  items  are  discussed 
in  the  following  section  (Acquisition  of  Data) . 

3.2  ACQUISITION  OF  DATA 

This  activity  located  and  abstracted  the  citations 
referenced  in  the  Master  List  described  in  Section  3.1.  It 
combined  aspects  of  the  previous  activity  and  the  fol lowing 
analysis  task.  Articles  referenced  in  the  Master  List  were 
located  and  acquired.  Location  and  acquisition  was  accomplished 
in  several  ways.  Data  was  ordered  from  DDC ,  and  articles  were 
copied  from  journals  and  other  pertinent  literature.  Authors 
of  articles  were  contacted  and  data  subsequently  received 
through  the  mail.  During  the  reviews,  references  made  to  other 
citations  and  sources  found  in  the  principal  documents  were  also 
located  and  reviewed.  Further,  in  discussions  with  some  sources, 
identification  of  other  potentially  applicable  simulation 
developments  and  programs  were  brought  to  the  attention  of  SASC. 
However,  the  survey  revealed  no  simulation  that  singularly  met 
all  of  the  technical  criteria  described  in  Section  3.3. 

3.3  ANALYSIS 

The  analysis  task  resulted  in  identification  of  simulation 
programs  that  most  appropriately  exhibit  AFWAL/AAAS  applicability. 
These  are  identified  in  Section  IV.  The  selection  process  was 
based  upon  the  following  criteria,  which  encompass  the  technical 
objectives  outlined  in  the  Scope  (Section  2.1). 


1)  All  Software  -  This  was  a  firm  requirement  specified 

in  the  Statement  of  Work.  Therefore, 
to  receive  mention  in  this  section, 
the  simulation  program  had  to  be  all¬ 
software.  Simulation  efforts  utilizing 
special  hardware/software  approaches 
did  not  receive  consideration. 

2)  Applicability  -  This  refers  to  the  simulation's  ability 

to  effectively  support  the  investiga¬ 
tion  of  data  processing,  distributed 
processing,  time  division  multiplex  or 
fault  tolerant  systems. 

3)  Availability  -  This  refers  to  the  simulation's  design 

status:  whether  it  is  fully  or 
partially  operational  or  in  development. 
Also,  accessibility  is  considered  in 
terms  of:  compatibility  with  existing 
computational  hardware  and  software 
resources,  or  whether  AFWAL/AAAS  access 
is  attainable  through  other  means  such 
as  terminals  or  other  available  communi¬ 
cation  nets. 

The  simulations  that  were  found  to  be  minimally  acceptable 
in  accordance  with  above  requirements  are  described  in  the  Compen¬ 
dium  (Section  VI)  in  terms  of  their  inherent  attributes  and  the 
relevance  of  these  attributes  to  AFWAL/AAAS  desired  applications. 
The  attributes  reflect  the  technical  and  design  aspects  a  user 
requires  to  effectively  model  and  simulate  a  particular  problem. 

Data  used  in  making  these  determinations  included  program 
descriptions,  specialized  reports,  user  manuals,  and  in  some 
instances,  marketing  literature.  In  short,  the  maximum  that  could 
be  obtained  from  the  respective  source.  There  were  instances 
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where  SASC  was  only  able  to  obtain  a  single  document  describing 
a  particular  simulation;  such  as  a  program  listing  or  user's 
manual.  For  these  conditions  attempts  were  made  to:  (a)  obtain 
more  data,  and  (b)  arrange  for  a  technical  discussion  with  the 
respective  source.  Thus  the  discussion  of  simulation  attributes 
is  based  upon  documented  and  undocumented  factors. 

Simulation  Attributes 

Five  attributes  or  factors  were  identified  as  the  most 
relevant  for  describing  and  evaluating  the  candidate  simulations. 

A  description  of  each  attribute  follows: 

1)  Performance  -  Refers  to  computer  time  required  to  compile  and 

execute  a  problem,  as  well  as  the  ratio  of  CPU 
time  to  simulated  time.  This  ratio  varied 
widely  among  the  systems  surveyed:  the  three 
systems  discussed  in  the  following  section  had 
a  range  of  ratios  from  15:1  to  2:7.  No  absolute 
standard  of  performance  was  utilized,  due  to  the 
difficulty  in  even  locating  simulations  that  met 
the  criteria  described  earlier  in  this  section. 

In  the  ensuing  discussions,  performance  will  be 
addressed  with  regard  to  AFWAL  applications  and, 
where  possible,  correlated  to  the  potential 
avionics  application. 

2)  Simulation  Capacity  -  Denotes  the  ability  of  the  simulation 

to  accommodate  large  models.  For  example,  for 
a  distributed  network,  are  there  unreasonable 
limitations  placed  on  the  number  of  nodes  that 
can  be  simulated  because  of  restrictive  design 
or  host  system  memory  requirements? 

3)  Ease  of  Use  -  Refers  to  user/simulation  interface  requirements. 

Factors  considered  here  include: 
a)  Simulation  Set-Up  Time.  This  considers  the 
overall  effort  and  time  required  to  learn 
the  system,  and  to  subsequently  build  and 
develop  a  model  from  a  design. 
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b)  Input  Language  Requirements.  This  considers 
how  readable  the  input  language  is  and  how 
quickly  models/problems  can  be  defined  for 
input. 

c)  Diagnostics .  This  refers  to  the  ability  of 
the  simulation  to  recognize  and  effectively 
flag  and  report  input  errors  of  format  and 
content. 

d)  Flexibility.  This  considers  the  design 
aspects  of  the  simulation  as  it  relates  to 
providing  libraries  of  routines  from  which  to 
develop  models  for  different  applications, 
and  providing  the  user  options  to  select 
different  levels  of  simulation  (i.e.,  func¬ 
tional  level  or  detailed  interpretive  level) . 

e)  Output  and  Reports ♦  This  relates  to  the  us¬ 
ability  and  range  of  output  data  provided  by 
the  simulation.  Considered  here  are  readability 
and  formats,  ability  to  provide  output  via 
charts,  graphs,  or  computerized  graphics. 

4)  Accessibility  -  Addresses  the  requirements  for  hosting  the 

simulation  on  AFWAL/AAAS  available  resources  and 
the  requirements  for  obtaining  access  to  the 
simulations  not  compatible  with  these  resources . 

5)  Documentation  -  Refers  to  the  availability  of  information  that 

describes  the  simulation  in  terms  of  user  inter¬ 
face  requirements  and  capabilities,  and  system 
design  descriptions  and  maintenance  manuals. 


SECTION  IV 


SURVEY  RESULTS 

4.0  CANDIDATE  SIMULATION/MODELING  SYSTEMS 

The  survey  has  resulted  in  the  identification  of  three 
(3)  simulation  and  modeling  systems  that  exhibit  the  technical 
and  operational  potential  to  satisfy  AFWAL/AAAS  analysis  require¬ 
ments.  Each  candidate  is  all-software,  accessible  to  the  Air 
Force,  and  operational  in  terms  of  past,  current,  and  intended 
future  use  in  supporting  design  analysis  activities.  The  three 
systems  are: 

1)  Generalized  Computer  System  Simulator  (GCSS) 

2)  Data  System  Dynamic  Simulator  (DSDS) 

3)  Design  Analysis  System/Distributed  Data  Processing 
Model  (DAS/DDPM) 

Special  Note:  The  DSDS  and  DAS/DDPM  were  found  as  a  result  of 
an  activity  being  conducted  by  ASD/MITRE,  Hanscomb  Air  Force  Base, 
Massachusetts.  ESD/MITRE  is  conducting  a  program  consisting  of 
the  identification,  evaluation  and  acquisition  of  a  computer 
communications  system  performance  model  to  effect  conceptual 
phase  analysis  of  C^  systems.  The  identification  and  evaluation 
efforts  have  been  completed. 

Two  additional  systems  were  included  in  the  ESD/MITRE 
effort:  Performance  on  Cost  Analysis  Model  (PERCAM)  and  Auto¬ 

mated  Requirements  Engineering  System  (ARES) .  These  systems 
were  eventually  dropped  by  this  study  because  of  their  current 
operational  status.  The  specific  reasons  are  provided  in  Section 
VI  (The  Compendium) . 

4.1  GENERALIZED  COMPUTER  SYSTEM  SIMULATOR  (GCSS) 

4.1.1  INTRODUCTION  TO  GCSS 

The  GCSS  represents  the  only  "find"  that  was  designed 
specifically  with  avionic  networks  and  processing  as  the  target 
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function.  The  system  was  identified  during  the  DDC  search. 

The  GCSS  is  operational  under  the  auspices  of  the  Naval 
Air  Development  Center  { NADC )  Warminster,  Pa.  The  system  will  be 
used  to  evaluate  alternative  system  architectures  and  signal 
processing  requirements  for  the  V/STOL  avionics  system. 

The  system  is  a  product  of  Honeywell's  Aerospace  and 
Ground  Systems  Group,  Minneapolis,  Minnesota.  During  the  past 
year  it  has  been  undergoing  enhancements  and  modifications. 

These  include  implementation  of  an  interactive  system,  improving 
the  user  interface  and  mods  to  make  it  work  as  intended. 

The  system  is  accessible  to  the  AFWAL ,  via  the  ARPANET. 

The  system's  software  support  requirements  preclude  hosting  on 
WPAFB  computers.  At  NADC  the  GCSS  is  hosted  in  a  CDC  6600. 
However,  it  is  programmed  in  SNOBOL  and  SIMSCRIPT  1.5;  neither 
language  is  supported  locally.  Therefore,  local  hosting  is  not 
feasible.  On  the  other  hand,  both  WPAFB  and  NADC  CDC  6600 
systems  are  nodes  on  the  ARPANET.  Thus  access  to  the  system  can 
be  achieved  remotely.  A  detailed  discussion  of  GCSS  is  presented 
in  the  following  section. 

4.1.2  GCSS  DESCRIPTION 

Source 

Naval  Air  Development  Center,  Warminster,  Pennsylvania 

Contact 

Mr.  C.  Mattes,  Mr.  W.  Garrison 

Application 

Computer  Architecture,  busing  arrangements  signal 
processing. 

Reference  Data 

NADC  "Installation  Validation  and  Support  of  the  Honeywell 
Generalized  Computer  System  Simulator  (GCSS),  Final  User's  Manual 
Contract  No.  N62269-77-C-0179 :  Honeywell  Systems  and  Research 
Center,  Aerospace  and  Defense  Group,  April  19,  1979. 

Note:  This  manual  addresses  the  batch  version  of  GCSS. 

The  interactive  system  is  not  documented. 
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Description 

GCSS  is  an  all-software  simulation  system  that  enables 
the  user  to  evaluate  the  throughput  and  occupancy  of  distributed 
processing  system  models  as  functions  of  hardware  and  software. 

The  system  is  hosted  on  a  CDC  6600  computer  and  is  programmed  in 
SNOBOL  and  SIMSCRIPT  1.5. 

The  principal  purpose  of  GCSS  is  to  assist  in  the  evalua¬ 
tion  of  an  alternate  computer  and  system  architectures  and  busing 
arrangements.  That  is,  the  simulator  provides  a  design  aid  for 
computer  systems'  performance  by  measuring  throughput  and  conflicts 
as  a  function  of  factors  that  include  element  interconnections, 
modularity,  instruction  repertoire  and  circuit  memory  technologies. 
User  documentation  states  that  "GCSS  is  best  suited  for  use  after 
the  system  level  requirements  have  been  defined  and  acceptable 
architectures  have  been  determined,  and  prior  to  preparation  of 
hardware  specifications". 

Three  major  components  and  steps  comprise  and  constitute 
a  complete  GCSS  execution.  They  are: 

•  IPP  -  Initialization  Pre-Processor 

•  SORT/MERGE  -  External  Events  Ordering 

•  GCSS  -  Simulator 

Figure  1  presents  a  pictorial  representation  of  this  environment. 

The  IPP  process  formats  and  derives  initialization  infor¬ 
mation  from  user  provided  input  data.  There  are  two  types  of  input 
required.  First,  there  are  thrity-one  (31)  User  Initialized 
Variables  (UIVs)  which  describe  the  physical  and  operational  char¬ 
acteristics  of  the  modeled  system.  Although  many  UIVs  have  complex 
functions,  for  example  MCHAN  which  describes  all  job  modules  in  the 
simulation,  most  are  straightforward:  RSTA  is  a  flag  array,  MDIO 
is  the  number  of  direct  I/O  devices  in  the  simulation.  Table  1 
contains  a  list  of  all  UIVs,  and  a  brief  description  of  each. 

Second  are  the  simulation  control  and  events  data  that  are  input 
via  the  external  events  portion  of  the  input  data.  These  data  are 
executed  on,  reformatted,  crosschecked  for  errors,  etc.  The 
resultant  output  serves  as  the  input  to  SORT /MERGE  and  GCSS  functions. 
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Fig  1  THE  GCSS  BATCH  RUN  ENVIRONMENT 


TABLE  1.  USER  INPUT  VARIABLES  OF  GCSS 


NAME  USE 

1.  NPE  Number  of  Processing  Elements  in  the  Simulation 

2.  NMD  Number  of  Memory  Devices  in  the  Simulation 

3.  NPIO  Number  of  Program  I/O  Devices  in  the  Simulation 

4.  NDIO  Number  of  Direct  I/O  Devices  in  the  Simulation 

5.  NMODS  Number  of  Program  Modules  in  the  Simulation 

6.  MILEV  Maximum  Interrupt  Level  in  the  System 

7.  NBVSS  Number  of  General  Buses  in  the  Simulation 

8.  NPIOB  Number  of  Program  I/O  Buses  in  the  Simulation 

9.  MEMCY  Array  of  Read  and  Write  Times  for  Each  Memory  Device 

10.  MCHAN  Central  Array  of  Simulation,  Describing  all  Modules  in 

the  Simulation 

11.  IOCYC  Array  of  Cycle  Times  for  Each  PIOD 

12.  SELMD  Array  Ordering  Modes  (Round  Robin,  Random,  Priority)  for 

Bus  Selection 

13.  ORSTT  Table  Setting  ORed  Successor  Probabilities  and  Paths 

14.  IREPT  Array  Describing  the  Processor  Instruction  Repertoire 

15.  IMIX  Table  Describing  the  Instruction  Mix  for  Each  Module 

16.  PDUV  Vector  Ordering  PEs  or  DIODs  for  Selection  by  Scheduler 

17 .  MDUV  Vector  Ordering  MDs  for  Selection  by  Scheduler 

18.  PIOUV  Vector  Ordering  PIOs .for  Selection  by  Scheduler 

19.  IRESP  Array  Fixing  Responding  Modules  for  Each  Interrupt  Level 

20.  BWTIM  Delay  Time  Before  Processors  Access  (Read  or  Write) 

General  Bus 

21.  PBWTM  Delay  Time  for  Processor  Elements  Access  (Read  or  Write) 

General  Bus 

22.  MISET  Vector  Establishing  Interrupt  Schemes  for  Each  Module 

23.  PEBM  Array  to  Show  Interconnections  of  PEs  (Row)  to  General 

Buses  (Colm) 

24.  MDGBM  Array  to  Show  Interconnections  of  MDs  (Row)  to  General 

Buses  (Colm) 

25.  PEPCM  Array  to  Show  Interconnections  of  PEs  (Row)  to  PIOBs  (Colm) 

26.  PI PCM  Array  to  Show  Interconnections  of  PIODs  (Row)  to  PIOBs 

(Colm) 

27.  DIGBM  Array  to  Show  Interconnections  of  DIODs  (Row)  to  General 

Bus  (Colm) 

28.  MAOPT  Logical  Switch  Noting  Fixed  or  Dynamic  Memory  Device 

Assignments 

29.  PIOPT  Logical  Switch  Noting  Fixed  or  Dynamic  PIO  Device 

Assignments 

30.  BSUL  List  Ordering  Devices  for  Bus  Utilization 

31.  RSTA  Flag  Noting  Requirement  to  Output  a  Particular  Report 


The  SORT/MERGE  function  orders  the  external  events 
according  to  predefined  time  fields  specified  with  the  appropriate 
event.  The  result  is  an  ordered  external  events  list  according 
to  the  time  of  occurrance  associated  with  each  event  of  the 
system  being  modeled.  This  output  serves  as  an  input  to  GCSS. 

GCSS  is  the  simulator.  GCSS  accepts  and  executes  upon  the 
model  characterized  by  the  sorted  external  events  data  from 
SORT/MERGE,  and  the  initialization  data  output  from  IPP.  The 
resultant  output  is  a  series  of  reports  and  traces  which  allows 
the  user  to  evaluate  the  model's  performance. 

Examples  of  the  types  of  processing  structures  that  can 
be  evaluated  by  GCSS  are  shown  in  Figures  2. a  and  2.b.  The  user 
describes  the  system  to  be  simulated  in  terms  of  the  number  and 
characteristics  of  the  processing  elements  (PE's),  direct  I/O 
devices  (DIO's),  memory  devices  (MEM's),  program  controlled  I/O 
devices  (PIO's),  and  the  interconnections  between:  a)  PE's  and 
PIO's,  b)  PE's  and  MEM's,  and  c)  DIO's  and  MEM's.  These  elements, 
which  are  the  basic  building  blocks  of  GCSS,  are  described  as 
follows : 

•  PE  -  Processing  Elements  or  CPUs 

•  Dio  or  DIOD  -  Direct  I/O  Devices;  another 
name  for  a  Direct  Memory  Access  device. 

•  PIO  or  PIOD  -  Program  Controlled  I/O  Device; 
data  transferred  under  control  of  a  PE.  (An 
anology  can  be  drawn  between  a  PIOD  and  an 
avionics  sensor.) 

•  MEM  or  MD  -  Memory  Device;  passive  element  of 
a  model.  Data  is  exchanged  with  a  memory 
device  either  a  word  at  a  time  or  in  blocks 
of  user  specified  size  under  control  of  a 

PE  or  DIOD. 

•  PIOB  -  PIO  Bus;  buses  that  connect  PEs  with 
each  other  or  with  PIODs. 

•  GBUS  -  General  Bus;  buses  that  connect  primarily 
devices  with  each  other  and  memory  devices 

(PES  aiid  DIODs.) 


-16- 


Thus  distributed  architectures,  multicomputer,  and  multi¬ 
processor  configurations  can  be  modeled  by  stipulating  types  of 
hardware  elements  and  their  respective  interconnections. 

In  addition  to  the  hardware  structures ,  GCSS  requires 
definition  of  the  structure  of  the  applications  software.  The 
characteristics  of  the  system's  software/program  modules  and  the 
interrelationships  between  modules.  Modules  include  instruction 
mix,  total  number  of  instructions,  amount  of  data  being  passed, 
interation  intervals,  and  priorities.  Module  interrelationships 
are  described  by  specifying  the  modules  that  must  succeed  a  given 
module  and  the  number  of  predecessors  that  require  completion 
prior  to  initiating  a  module.  These  and  the  physical  system 
characteristics  are  defined  via  the  user  provided  UIV's  and 
external  events  data. 

GCSS  provides  the  user  the  option  to  determine  the  level 
of  simulation  detail  desired.  These  levels  can  range  from  inter¬ 
actions  on  a  module  to  module  basis  to  representation  of  every 
memory  cycle  of  every  instruction.  GCSS  allows  the  user  to 
specify  module  execution  characteristics  in  terms  of  a  block  of 
execution  time  down  to  a  string  of  memory  read  and  write  cycles. 

Simulation  output  reports  are  tabular.  They  include 
measures  of  the  resource  utilization  per  program  module,  percent 
utilization  of  processing  elements  and  storage  capacity,  bus 
traffic  levels,  queue  sizes  and  time  delays.  Specific  outputs 
available  at  various  levels  include: 

•  Statistics  on  the  average  amount  of  time 
required  to  complete  each  module  or 
program  section. 

•  Average  number  and  duration  of  interrupts 
that  occur  throughout  the  run. 

•  Scheduling  delay  statistics. 

•  Utilization  statistics  on  each  piece  of  hardware. 

•  Size  statistics  on  the  various  queues  that 
develop  throughout  the  system. 

A  sample  of  GCSS  outputs  is  shown  in  Table  2. 
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When  modeling  any  system,  GCSS  requires  initialization 
of  the  thirty-one  (31)  UIV's.  These  user  defined  variables  are 
derived  from  the  model's  hardware  and  program  module  (software) 
physical  and  operational  characteristics.  The  hardware  character¬ 
istics  are  derived  from  diagrams  of  the  type  shown  in  Figure  2(a) 
and  2(b).  This  allows  the  user  to  specify  the  various  types  of 
elements  and  their  interconnections.  To  specify  the  program  module 
characteristics,  the  user  must  develop  a  concept  of  how  the 
system  is  to  operate.  Specifically,  the  user  defines  the  order 
in  which  bus  selection  algorithms  are  enforced,  which  priorities 
are  assigned  to  hardware  units  to  resolve  conflicts,  and  what 
unique  groups  of  primary  devices  are  required  to  accomplish  each 
of  the  jobs  to  be  performed.  Additionally,  definitions  of  the 
number  of  modules  in  the  system,  module  "interation  rates  for 
specific  modules,  and  module  execution  sequences  are  required". 
Software  control  flow  diagrams  called  "chaining  diagrams"  are 
used  for  these  purposes. 

Chaining  diagrams  depict  the  model  environment  by  specify¬ 
ing  the  interdependency  of  the  various  program  modules.  Critical 
UIV  data  is  derived  from  the  chaining  diagram.  Each  module  is 
uniquely  numbered  which  allows  the  user  to  specify  unique  opera¬ 
tional  characteristics  to  each  module  and  assign  modules  to  PE’s. 

Program  chaining  is  based  on  four  building  blocks.  These 

are: 

•  ANDed  Successor 

•  Statistical  Successor 

•  ANDed  Predecessor 

•  ORed  Successor 

Examples  of  these  appear  in  Figure  3.  Figure  4  is  an  example  of 
how  these  four  building  blocks  can  be  combined  to  form  a  subsystem 
model. 

ANDed  Successor  means  all  modules  chained  to  a  particular 
module  are  enabled  when  that  particular  module  is  completed. 

Statistical  successor  allows  conditional  branching  to  a 
particular  module  a  percentage  of  time  based  upon  a  random  number. 
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ANDed  predecessor  means  all  modules  chained  to  a  particular 
module  must  be  completed  prior  to  initiation  of  that  module. 

ORed  predecessor  is  the  condition  where  the  completion  of 
either  module  is  sufficient  to  initiate  the  succeeding  module. 

While  GCSS  provides  ample  diagnostic  capability  to  the 
user,  the  interactive  system  employs  a  unique  capability  that 
allows  the  user  to  validate  the  modeled  system  configuration 
prior  to  execution.  Through  use  of  the  interactive  graphics 
display  terminal,  GCSS  displays  back  to  the  user  block  diagrams 
and  chaining  diagrams  of  the  type  that  appear  in  Figure  1  and 
Figure  3,  which  characterize  the  model's  physical  and  functional 
relationships.  This  data  is  derived  from  the  user  input  data. 

Thus  the  user  is  able  to  validate  the  model  to  be  executed  against 
the  intended  physical  and  functional  relationships  prior  to  actual 
execution. 

System  Attributes  -  GCSS 

Performance  -  Few  data  points  are  available  that  would  support 
a  valid  assessment  regarding  performance.  An 
example  provided  to  SASC  showed  seven  seconds  of 
CPU  time  required  to  process  two-seconds  of 
simulated  time.  The  model  being  considered  con¬ 
sisted  of  seven  PE's,  seven  MD's,  fourteen  GBUS's, 
two  PIOB's,  two  PIOD's,  and  four  DIOD's. 

Simulation  Capacity  -  GCSS  has  the  capacity  to  simulate  1024  each 
of  PE's,  MEM's,  PIOD's,  DIOD's  and  their  bus  inter¬ 
connections  . 

Ease  of  Use  -  GCSS  requires  no  special  programming  skills  to 
describe  or  execute  a  model.  Model  development 
times  are  essentially  a  function  of  the  complexity 
of  the  model  being  simulated  and  the  desired  level 
of  planned  analysis. 

Input  Language  -  At  present  GCSS  uses  no  special  HOL  for  the  user 
to  interface  with  the  system.  The  thirty-one  UIV's 
have  an  established  protocol  that  is  relatively 
cumbersome  to  handle  for  large  models.  However  an 
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effort  is  currently  underway  to  enhance  the  user 
interface  by  developing  a  "Concise  Architecture 
Description"  language  in  APL.  Upon  completion, 
it  is  anticipated  that  model  build  times  can  be 
reduced  by  approximately  fifty  percent. 

Flexibility  -  GCSS  offers  flexibility  in  terms  of  the  types  of 
data  processing  architecture  that  can  be  modeled 
and  the  various  levels  of  analysis  that  can  be 
conducted.  Types  of  architectures  include  multi¬ 
processing,  distributed  processing,  and  multicomputer. 
Analysis  levels  can  be  conducted  at  higher  functional 
levels,  detailed  instruction  levels  or  combinations 
of  both. 

Outputs  and  Reports  -  A  comprehensive  set  of  statistical  output 

reports  is  available  to  the  user  regarding  through¬ 
put,  queue  sizes,  etc. ,  for  each  user  defined  model 
element.  These  are  provided  via  formatted  data  on 
program  listings  upon  completion  of  the  simulation 
run.  Graphical  output  is  currently  limited  to 
the  previously  mentioned  system  block  and  chaining 
diagrams  used  to  validate  user  input  data  and  only 
on  the  interactive  system. 

Accessibility  -  GCSS  compatibility  with  available  AFWAL/AAAS 

resources  exists  only  in  terms  of  the  host  computer 
system  (CDC  6600)  .  Software  resources  are  not 
compatible.  The  CDC  system  at  NADC  uses  the  KRONOS 
operating  system,  whereas  the  local  WPAFB  CDC 
system  runs  under  NOS/BE.  Also,  GCSS  is  written 
in  SIMSCRIPT  1.5  which  is  not  supported  locally. 

These  incompatibilities  create  large  portability 
problems.  However,  the  NADC  system  is  tied  into 
the  ARPANET  system  as  is  the  local  WPAFB  system. 

Thus,  access  to  GCSS  can  be  obtained  over  this 
network.  Accomplishing  this  interface  will  require 
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an  access/authorization  code  to  enable  access  to 
the  NADC  system  and  the  hardware  elements  (i.e., 
interactive  graphics  display  terminal,  hard  copy 
device  line  printer  and  modem)  necessary  to  support 
the  transactions. 

Documentation  -  There  is  no  documentation  that  is  representative 

of  GCSS  as  it  is  currently  configured.  This  applies 
to  description  of  the  simulator  as  well  as  user 
manuals.  A  batch  system  user  manual  is  available; 
however,  if  AFWAL  chooses  to  use  GCSS,  an  interactive 
system  user  manual  will  be  required. 

4.2  DATA  SYSTEM  DYNAMIC  SIMULATOR  (DSDS) 

4.2.1  INTRODUCTION  TO  DSDS 

The  DSDS  was  developed  by  General  Electric  Corporation  for 
the  National  Aeronautical  and  Space  Administration  (NASA) ,  under 
the  direction  of  the  Marshal  Space  Flight  Center  (MFSC) , 

Huntsville,  Alabama.  The  system  was  designed  to  model  and 
simulate  large  data  processing  and  communication  systems  and 
their  respective  operational  and  cost  characteristics.  The  system 
features  a  library  of  preprogrammed  models  characterizing  about 
150  elements  used  in  communications  and  data  processing  needs  in 
the  1985  to  1990  time  frame. 

The  DSDS  is  operational  in  two  modes.  A  batch  version  of 
DSDS  was  developed  on  an  IBM  360/75  computer.  An  interactive 
system  is  being  developed  on  a  PRIME  400  system,  and  is  basically 
IBM  360  compatible.  The  batch  version  is  available  to  outside 
agencies.  The  system  is  accessible;  in  fact,  ESD/MITRE  is 
currently  installing  the  batch  version  of  DSDS  on  their  IBM  370 
computer  to  conduct  in-house  assessments  of  the  system. 

The  system  is  programed  using  GASP  IV  for  system  and^ 
control  functions  and  FORTRAN  IV  for  lower  level  functions. 

Thus  rehosting  efforts  should  not  pose  insurmountable  problems. 

A  more  detailed  discussion  of  the  system  is  presented  in  the 
following  section. 
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4.2.2 


DSDS  DESCRIPTION 


Source 

National  Aeronautical  Space  Administration,  Marshall  Space 
Plight  Center,  Huntsville,  Alabama 

Contact 

Mr.  John  R.  Piner  -  NASA/MSFC 

Mr.  Norman  F.  Geer  -  GEC 

Reference  Data 

NASA  "Training  Manual  For  Data  Systems  Dynamic  Simulator" 
General  Electric  Company,  Space  Division,  Huntsville,  Alabama, 
September  1,  1978. 

NASA  "Study  to  Establish  Models  and  Simulation  for  Data 
Systems,  Volume  2  Users  Manual",  General  Electric  Company,  Space 
Division,  Huntsville,  Alabama,  July  28,  1978. 

NASA  "Spacelab  Simulation,  SL-l  Model  Implementation 
Report",  General  Electric  Company,  Space  Division,  Huntsville, 
Alabama,  March  1979. 

Application 

Communication  and  Data  Processing  Systems. 

Description 

The  DSDS  is  a  discrete  event  driven  simulation  system 
designed  for  performing  design  analysis  of  satellite  communications 
and  ground  data  processing  systems.  The  system  is  programmed  in 
FORTRAN  IV  and  uses  a  modified  version  of  GASP  IV  for  system  level 
functions  and  control.  The  system  is  operative  in  a  batch  mode 
on  an  IBM  360/65  and  an  interactive  mode  on  a  dedicated  PRIME  400 
system.  DSDS  features  modeling  capabilities  that  include  hardware, 
software,  human  operations,  and  system  characteristics  that  include 
timing,  control,  sizing,  external  influences,  and  cost. 

The  DSDS  model  development  is  based  upon  basic  modeling 
entities  called  Data  System  Element  Models  (DSEMs) .  These  are 
FORTRAN  representations  of  real  systems  elements  such  as  sensors, 
peripheral  devices,  processors,  software  tasks,  etc.  When 
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developing  models,  DSEMs  are  interconnected  to  form  complete 
system  models  by  directing  the  output  from  one  DSEM  to  the  input 
terminal  of  another.  Thus  subsets  of  DSEMs  are  interconnected 
to  characterize  a  complete  system  model  which  is  thus  tailored 
to  the  user's  needs.  Figure  5  illustrates  the  concept  of  inter¬ 
connecting  DSEMs. 

The  DSDS  maintains  a  model  library  of  approximately 
150  DSEMs.  These  models  are  representative  of  system  elements  and 
functions  common  to  the  current  application  of  satellite  communica¬ 
tions  and  ground  data  processing  systems.  Table  3  lists  many  of 
the  DSEMs  currently  in  the  library.  In  the  library,  as  indicated 
by  the  tables,  DSEMs  are  maintained  at  three  levels  of  detail  - 
Global,  Intermediate  and  Subsystem,  where  Global  level  DSEMs  are 
the  least  detailed  and  Subsystem  level  DSEMs  are  the  most  detailed. 
DSDS  allows  the  interconnection  of  DSEMs  of  different  levels. 

This  feature  results  in  savings  of  modeling  and  computer  execution 
times  when  using  Global  level  DSEMs  because  they  execute  their 
respective  elements  at  the  level  of  detail  modeled. 

At  the  system  level,  DSDS  is  comprised  of  six  core  models 
that  perform  the  functions  of  control,  event  scheduling,  statis¬ 
tical  data  gathering  and  reporting.  Figure  6  shows  the  core 
models  and  their  interrelationships.  Descriptions  of  their 
functions  are  discussed  below. 

1)  Mission  Model  (MM)  -  MM  is  the  DSDS  simulation  driver. 
It  generates  the  sequences  of  events  which  results 

in  data  generation,  routing  and  control  based  upon 
the  users  source  input  data. 

2)  Throughput/Resource  Utilization  Model  (TRUM)  -  This 
is  the  simulation's  mathematical  and  logic  model.  It 
represents  the  functional  operation  of  the  modeled 
system  and  is  the  mode  through  which  all  data  flows. 

3)  Device  Utilization  Model  (DUM)  -  This  is  the  simulation 
systems  instrumentation  element.  The  DUM  provides 

the  reporting  functions  for  the  simulation. 
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TABLE  3.  EXAMPLES  OF  AVAILABLE  DSDS  DATA  SYSTEM  ELEMENT  MODELS 
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TABLE  3.  EXAMPLES  OF  AVAILABLE  DSDS  DATA  SYSTEM  ELEMENT  MODELS  (Continued) 
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NOTE:  DSEMs  marked  with  an  asterisk  (*)  are  those  of  special  interest  to  AFAL. 
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4)  Operations  Model  COM)  -  This  model  performs  the 
scheduling  and  allocation  of  human  resources  required 
to  support  the  flow  of  data  in  the  system. 

5)  Cost  Model  (CM)  -  This  is  the  system's  cost  estimator. 
It  provides  cost  estimates  of  system  acquisition  and 
operation. 

6)  Integrated  Model  (IM)  -  This  is  the  simulation  execu¬ 
tive.  IM  provides  the  overall  control  functions  for 
the  other  five  models. 

Performance  measurements  obtained  from  DSDS  simulations 
are  made  possible  by  logic  contained  in  each  DSEM.  This  logic 
duplicates  the  throughput,  utilization,  operational  support 
requirements,  computer  resource  requirements  and  cost  character¬ 
istics  of  the  element  represented  by  the  DSEM.  The  logic  is 
triggered  by  definitions  of  the  element's  operational  and  inter¬ 
connection  characteristics  assigned  by  the  modeler.  DSDS  requires 
a  set  protocol  for  each  DSEM  used  in  a  model.  Thus,  for  each 
DSEM,  there  is  a  unique  set  of  parameters  that  characterize  its 
operation. 

The  DSDS  maintains  an  up-to-date  users '  manual  which 
provides  the  model  developer  with  descriptions  of  all  available 
DSEMs  in  the  library.  Each  DSEM  has  an  associated  set  of  para¬ 
metric  codes  that  enables  the  user  to  define  the  characteristics 
of  the  modeled  device  as  it  pertains  to: 

•  Throughput  -  PARTRM 

•  Device  Utilization  -  PARDUM 

•  Operations  -  PAROM 

•  Cost  -  PARC ST 

In  addition  to  the  above,  the  user  is  prompted  about  DSEM 
use  with  operational  notes,  special  instructions,  and  block 
diagrams.  Figure  7  contains  the  block  diagram  for  an  Intermediate 
Level  DSEM  of  a  Loop  Recorder  with  Control.  This  is  the  basic 
element  from  which  the  other  DSEM  elements  are  derived. 

The  cost  data  for  the  DSEM,  diagrammed  in  Figure  7,  is 
as  follows: 


-32- 


LOSE  DATA 


Figure  7.  Intermediate  Level  DSEM  of  Loop  Recorder 

With  Control:  Internal  Logic  Diagram  (Concluded) 


PARAMETER 

DESCRIPTION 

UNITS 

RANGE 

DEFAULT 

1 

SUBCLASS  IDENTIFIER 
1-FLIGHT,  2-GROUND 

WHOLE 

NUMBERS 

0,  2.0 

0.0 

O 

4- 

USER-DESIGNATED 

SPECIFIC  COST 

DOLLARS 

OPEN 

10K 

3 

FIRST  DRIVING  COST 
(EXEC.  TIME) 

SECONDS 

30-30K 

5K 

1* 

SECOND  DRIVING  COST 
(WEIGHT) 

KGM 

1-20 

3 

5 

THIRD  DRIVING  COST 
(RESERVED  FOR  FUTURE 
USE) 

N/A 

N/A 

0.0 

6 

FOURTH  DRIVING  COST 
(RESERVED  FOR  FUTURE 
USE) 

N/A 

N/A 

0.0 

6a 

OPTIONAL-MULTIPLE  USE 
KEY 

NEGATIVE 

WHOLE 

NUMBERS 

-1.0  to 
-9.0 

0.0 

Similarly,  the  parametric  data  for  the  DSEM  in  Figure  7 
is  displayed  below: 


PARAMETER  NO. 

USER 

INPUT 

DEFAULT 

VALUE 

DESCRIPTION 

Thruput  Model 

PARTRM ( 1 ) 

YES 

1. 

PRIORITY  FOR  CHANGE  TAPE 

PARTRM(2) 

YES 

2. 

PRIORITY  FOR  READ 

PARTRM ( 3 ) 

YES 

3. 

PRIORITY  FOR  WRITE 

PARTRM ( L ) 

YES 

7. 

WRITE  RATE  -  LOW  (IPS) 

PARTRM ( 5 ) 

YES 

15. 

WRITE  RATE  -  HIGH  (IPS) 

PARTRM ( 6 ) 

YES 

7. 

READ  RATE  -  LOW  (IPS) 

PARTRM ( 7 ) 

YES 

15. 

READ  RATE  -  HIGH  (IPS) 

PARTRM ( 8 ) 

YES 

15. 

LENGTH  OF  TAPE  ( FT . ) 

PARTRM ( 9 ) 

YES 

90. 

TIME  TO  CHANGE  TAPE  (SEC.) 

Device  Utilization  Model 

PARDUM(l) 

YES 

0. 

CAPACITY 

PARDUM( 2 ) 

YES 

0. 

IS  TIME  POINT  DATA  DESIRED,  0-No,  1-YES 

Operations 

Model 

PAROM(l) 

YES 

1. 

HOW  MANY  SUPPORT  SKILLS 

PAR0M(2) 

YES 

2204. 

OPERATING  SKILL  § 1 

PAR0M(3) 

YES 

1. 

HOW  MANY  OF  OPERATING  SKILL  H 1  ARE  REQUIRED 

PAROM(L) 

YES 

8107. 

SUPPORT  SKILL  #1 

PAROM ( 5 ) 

YES 

.05 

USE  RATE  SUPPORT  SKILL  § 1  (HRS/HR) 

parom(6) 

SUPPORT  SKILL  #2 

PAROM(7) 

USE  RATE  FOR  SUPPORT  SKILL  #2  (HRS/HR) 

parom(8) 

SUPPORT  SKILL  #3 

PAROM ( 9 ) 

USE  RATE  FOR  SUPPORT  SKILL  #3  (HRS/HR) 
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The  textual  material,  which  completes  the  data  needed 
for  the  DSEM  in  Figure  7,  consists  of  Operational  Notes  and 
Special  Instructions. 

Operational  Notes  -  This  tape  recorder  model  is  capable 
of  writing  data  (records) ,  reading  data  (play  back) , 
changing  tape,  and  stopping  for  maintenance.  These 
operations  are  given  priorities  by  the  user  except  for 
maintenance  which  always  has  top  priority.  If  the  recorder 
is  in  the  process  of  reading,  and  the  recorder  is  shut 
down  for  maintenance,  the  read  operation  is  immediately 
halted.  The  same  is  true  for  the  write  operation.  The 
change  tape  operation  will  ignore  maintenance  and  will 
finish  before  the  tape  recorder  is  shut  down.  If  the 
recorder  is  busy  with  one  of  these  operation  other  than 
maintenance  and  receives  control  for  other  operations 
of  a  higher  priority  then  the  controls  are  queued  by 
priority  and  must  wait  for  the  present  operation  to 
finish.  Data  is  lost  whenever  data  tries  to  enter  the 
recorder  and  no  write  command  has  been  given  or  the 
recorder  is  busy  doing  something  else.  Data  is  also 
lost  if  data  on  the  tape  that  has  not  been  read  is  written 
over. 

Special  User  Instructions 
1 .  Status  Outputs 

A.  End-of-Tape  Write  -  If  the  recorder  is  writing 
and  finds  the  end  of  the  tape  then  an  "ON" 
control  is  output  followed  by  an  "OFF"  control 
one  microsecond  later. 

B.  Busy  -  When  the  recorder  begins  reading  or  writing 
an  "ON"  control  is  sent  out.  If  at  the  end  of 
the  operation  the  next  request  in  the  queue  is 
the  other  operation  then  no  control  signal  is  sent 
out.  When  all  requests  for  reading  and  writing 
have  been  satisfied  or  one  of  these  operations  is 
interrupted,  then  an  "OFF"  control  is  sent  out. 
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C.  OFF  -  An  "ON"  control  is  sent  out  when  mainten¬ 
ance  starts  and  an  "OFF"  control  when  it  is  done. 

D.  End-of-Tape  Read  -  If  the  recorder  is  reading  and 
finds  the  end  of  the  tape  then  an  "ON"  control 

is  output  followed  by  an  "OFF"  control  one  micro¬ 
second  later. 

2.  The  smaller  the  number  entered  for  priority,  the 
higher  the  priority.  The  highest  priority  that  can 
be  entered  is  1. 

3.  When  an  "ON"  control  is  received  in  either  speed 
select,  the  recorder  switches  to  the  higher  speed. 

An  "OFF"  control  returns  the  recorder  to  low  speed. 

4.  A  change  tape  request  will  cause  the  recorder  to 
request  personnel.  If  the  oeprator  request  line 
has  been  given  a  zero  for  its  connection  then  the 
recorder  will  assume  it  has  a  person  dedicated  to  it 
and  go  ahead  with  changing  the  tape.  If  no  tapes 
have  been  received  then  a  blank  tape  is  mounted. 

Utilization  Definition  -  The  utilization  equals  100% 

when  the  recorder  is  showing  busy  on  its  status  line 

output  and  0%  the  rest  of  the  time. 

Figure  8  is  the  block  diagram  for  a  Subsystem  Level  DSEM 
of  a  Computer  Interface  Unit.  This  DSEM  has  no  associated  cost 
data,  and  its  parametric  data  is  as  follows: 


PARAMETER  NO. 

USER 

INPUT 

DEFAULT 

VALUE 

DESCRIPTION 

Thruput  Model 

PARTRM(l) 

YES 

1*. 

RANDOM  NUMBER 

CODE 

PARTRM(2) 

YES 

1. 

RANDOM  NUMBER 

FIRST  PARAMETER 

PARTRM(3) 

YES 

.5 

RANDOM  NUMBER 

SECOND  PARAMETER 

PARTRM( h ) 

YES 

1.5 

RANDOM  NUMBER 

THRID  PARAMETER 

PARTRM( 5 ) 

YES 

.0833 

RANDOM  NUMBER 

FOURTH  PARAMETER 

PARTRM(6) 

YES 

0. 

NOT  USED 

partrm( t ) 

YES 

526 

MAXIMUM  BITS  : 

IN  BUFFER 

PARTRM(8) 

YES 

1000. 

OUTPUT  DATA  RATE 

PARTRM(9) 

YES 

1000. 

MAXIMUM  RATE  FOR  INPUT  (BPS),  ALSO  THE  NUMBER 

OF  BITS  PROCESSED  IN  THE  RESOURCE  TIME 
SPECIFIED  IN  PARTRM(13),  (l6),  ETC. 


PARAMETER  NO. 

USER 

INPUT 

DEFAULT 

VALUE 

DESCRIPTION 

Thruput  Model 

PARTRM(IO) 

YES 

U. 

NUMBER  OF  RESOURCES 

PARTRM(ll) 

YES 

100. 

FIRST  RESOURCE  REQUIREMENT  CODE 

PARTRM(l2) 

YES 

1. 

FIRST  RESOURCE  REQUIREMENT  QUANTITY 

PARTRM(13) 

YES 

1. 

FIRST  RESOURCE  REQUIREMENT  TIME  (SECS.) 

PARTRM( lU ) 

YES 

5. 

SECOND  RESOURCE  REQUIREMENT  CODE 

PARTRM(15) 

YES 

1000. 

SECOND  RESOURCE  REQUIREMENT  QUANTITY 

PARTRM(l6) 

YES 

1. 

SECOND  RESOURCE  REQUIREMENT  TIME  (SECS.) 

PARTRM(17) 

YES 

3. 

THIRD  RESOURCE  REQUIREMENT  CODE 

PARTRM(l8) 

YES 

1000. 

THIRD  RESOURCE  REQUIREMENT  QUANTITY 

PARTRM(19) 

YES 

1. 

THIRD  RESOURCE  REQUIREMENT  TIME  (SECS.) 

PARTRM(20) 

YES 

106. 

FOURTH  RESOURCE  REQUIREMENT  CODE 

PARTRM( 21 ) 

YES 

1. 

FOURTH  RESOURCE  REQUIREMENT  QUANTITY 

PARTRM(22) 

YES 

1. 

FOURTH  RESOURCE  REQUIREMENT  TIME  (SECS.) 

Device  Utilization  Model 

*V 

PARDUM  NONE 


Operations  Model 

PAROM"\  NONE 

The  textual  and  final  portion  of  the  DSEM  in  Figure  8 
contains  instructional  material. 

Operational  Notes 

1.  The  CIU  will  shutdown  for  maintenance  when  an  off 
control  Event  Type  2  arrives  at  Pin  1.  It  will  start 
up  when  an  on  control  Event  Type  1  arrives  at  Pin  1. 

2.  When  a  Message  Stream  arrives  at  Pin  2,  it  will  be 
accumulated  into  a  message  transaction  (TX) .  The 
TX  will  be  placed  in  Queue  #1  in  order  of  arrival. 

If  a  complete  message  has  entered  the  CIU003,  resources 
are  requested. 

3.  When  the  resources  are  supplied,  the  TX  is  removed 
from  Queue  #1  and  output  on  Pin  2.  After  a  delay 
equal  to  the  maximum  resource  'use  time'  as  defined 
under  Special  User  Instructions,  the  resources  are 
returned  to  the  CPU003.  If  Queue  #1  is  not  empty, 
the  resources  are  requested  for  the  event  in  the  top 
of  Queue. 
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4.  When  a  TX  arrives  at  Pin  3,  it  will  be  placed  in 
Queue  #2.  If  Output  #1  is  not  busy,  resources  are 
requested  for  processing. 

5.  When  the  resources  are  supplied,  the  TX  is  spread 
into  a  Message  Stream. 

Special  User  Instructions 

1.  The  resource  Requirements  Table  (RRT)  is  entered  in 

PARTRM (10) .  Each  Resource  definition  requires  3 
parameters:  (1)  Resource  Code,  (2)  Resource  Require¬ 

ment  Quantity,  and  (3)  Resource  Requirement  Time. 

Refer  to  "Resource  Code  Table"  Appendix  #3  for  the 
code  and  quantity  definitions  of  each  resource. 

2.  The  maximum  number  of  bits  to  be  buffered  (e.g.,  on 
the  Disc)  limits  the  quantity  of  data  that  may  be 
stored  in  the  CIU003.  It  is  called  Maximum  Bits  in 
Buffer  and  entered  in  PARTRM (7). 

3.  The  Bit  Rate  for  the  output  message  stream  is  entered 
in  PARTRM (8)  . 

4.  The  Random  Number  distribution  code  and  parameters 
are  entered  in  PARTRM  (1  thru  5) .  The  'use  time' 
of  each  resource  is  determined  by  (Random  Number)  * 
(Number  of  bits  in  incoming  message  transaction)  * 
(resource  time  in  PARTRM ( 13 ) ,  (16),  etc.)  t  PARTRM ( 9 ) . 

Utilization  Definition  -  The  utilization  is  determined  by 

the  CPU003. 

Since  all  pertinent  performance  information  is  programmed 
into  each  DSEM,  DSDS  is  able  to  provide  performance  measurements 
from  simulations  at  system  and  element  levels  using  any  set  or 
combinations  of  DSEMs.  Performance  measurements  that  are  made 
available  are: 

•  Message  transit  time 

•  Average  transit  time 

•  Transit  time  between  any  two  points 

•  Mean  throughput,  utilization  and  transit  time  per 

element 


•  Storage  statistics  and  percent  utilization 

•  Tabular  throughput  timeline 

•  Computer  resource  utilization  summary 

•  Plot  of  storage  device  full 

Other  reports  include  personnel  skills  and  allocation 
requirements  from  the  operations  model  and  system  and  element 
cost  estimates  from  the  cost  model. 

It  is  significant  to  note  that  DSDS  has  no  operational 
constraints  or  limits  with  regard  to  the  number  of  DSEMs  that  can 
be  assigned  to  the  library  aside  from  the  host  system  physical 
storage  limits.  New  DSEMs  are  still  being  defined  and  added  to 
the  system.  This  capability  makes  DSDS  a  highly  flexible  tool 
with  the  potential  to  support  a  variety  of  data  processing  and 
information  processing  analysis  efforts. 

System  Attributes 

Performance  -  Typical  DSDS  performance  times  when  executing  to 
obtain  only  throughput  and  device  utilization  to 
the  subsystem  level  is  approximately  1:4.  That 
is,  it  takes  one  second  of  CPU  time  to  execute 
four  seconds  of  simulated  time.  Since  DSDS  is 
multi-functional  and  executes  in  multiple  levels, 
it  is  not  possible  to  quantify  its  performance 
as  a  constant. 

Simulation  Capacity  -  There  are  no  limits  placed  on  either  model 
size  (number  of  DSEMs)  or  the  number  of  events  that 
can  be  simulated  assuming  that  adequate  storage  is 
available.  Currently  a  full  program  load  is  1460K 
bytes.  In  its  present  configuration  disk  storage 
is  used  to  reduce  core  requirements  during  execution. 
Under  control  of  the  executive,  core  requirements 
are  approximately  350K  bytes. 

Ease  of  Use  -  DSDS  is  user  oriented.  The  concept  of  interconnect¬ 
ing  DSEMs  end-to-end  simplifies  the  model  development 
process.  User  aids  consisting  of  block  diagrams 
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of  DSEMs,  labeled  inputs,  outputs,  and  identifica¬ 
tion  of  element  characteristics  enhances  overall 
model  development  and  learn  times. 

Input  Language  -  The  DSDS  input  language  form  is  straightforward 
and  requires  no  special  skills.  User  inputs  are 
prepared  in  standard  NAMELIST  input  common  to 
FORTRAN  IV.  Each  DSEM  is  individually  specified 
within  a  NAMELIST  block  in  terms  of  throughput, 
device  utilization  and  interblock  connections.  An 
example  is  given  in  Figure  9. 

Flexibility  -  The  DSDS  exhibits  flexibility  in  areas  of: 

•  Design  -  The  system  can  simulate  almost  any 
data  processing  configuration  that  can  be 
conceived  provided  DSEMs  are  available. 

•  Analysis  -  Models  can  be  characterized  and 
performance  measured  at  three  functional 
levels  using  any  combination  of  DSEMs.  Types 
of  analysis  are  user  options,  i.e.,  cost, 
throughput,  device  utilization, or  operations. 

•  Growth  -  System  growth  is  limited  only  by 
physical  host  system  constraints  and  the 
ability  of  personnel  resources  to  develop  new 
DSEMs . 

•  Rehostability  -  Since  DSDS  uses  GASP  IV  or 
control  and  FORTRAN  IV  to  implement  DSEMs, 
rehosting  should  be  a  relatively  straight¬ 
forward  task. 

Outputs  and  Reports  -  Statistical  output  reports  are  available 
at  system  level  and  on  the  performance  of  each 
DSEM  in  a  given  model  independent  of  functional 
level.  The  reports  include  queue  statistics, 
throughput,  device  utilization,  operational 
resource  requirements  and  cost.  Graphical  out¬ 
puts  on  all  of  the  above  is  available  with  the 
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interactive  system.  A  sample  of  DSDS  output 
is  shown  in  Table  4 . 

Accessibility  -  Since  DSDS  uses  GASP  IV  or  FORTRAN  IV,  it  can 

probably  be  hosted  on  either  the  AFWAL  DEC  10,  or 
the  ASD  CDC  6600  computer  system.  The  batch 
version  is  available  through  the  University  of 
Georgia's  COSMIC  library  services. 

The  interactive  system  is  in  the  final  stages  of 
development  and  is  not  planned  for  release  to 
outside  agencies  until  late  1980.  In  either  case, 
it  would  be  advisable  to  solicit  specialized 
support  from  General  Electric  Corporation  to 
effect  the  rehosting  effort.  This  support,  along 
with  specialized  training  of  prospective  users  of 
DSDS,  can  be  obtained  from  General  Electric  Corpora¬ 
tion. 

Documentation  -  The  DSDS  is  accompanied  by  a  comprehensive  set 

of  user  oriented  documentation.  There  is  a  train¬ 
ing  manual  which  describes  the  system's  operation 
and  presents  sample  problems  illustrating  user 
input  formats  and  requirements  and  simulation  out¬ 
puts.  Additionally,  there  is  the  user's  manual 
which  covers  the  basic  design  and  use  of  all  system 
functions  and  includes  a  complete  and  current 
dictionary  of  all  DSEMs . 

4.3  DESIGN  ANALYSIS  SYSTEM/DISTRIBUTED  DATA  PROCESSING  MODEL 

(DAS/DDPM) 

4.3.1  INTRODUCTION  TO  DAS/DDPM 

The  DAS/DDPM  is  a  proprietary  simulation  and  modeling 
tool  developed  by  Hughes  Aircraft  Company  (HAC) ,  Fullerton, 
California.  The  system  is  a  product  of  evolving  simulation  and 
modeling  technology  development  fostered  by  in-house  research  and 
development  needs. 
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The  DAS  is  promoted  as  a  concept  and  a  simulation  and 
modeling  development  support  tool.  As  a  concept,  it  supports 
operation  analysis,  data  processing  design  analysis  and  software 
design  analysis.  As  a  tool  it  provides  a  sophisticated  inter¬ 
active  graphics-oriented  interface  design  to  enhance  the  users' 
interface.  The  DDPM  is  a  distributed  data  processing  model  which 
contains  a  library  of  models  representing  the  more  common 
components  found  in  distributed  data  processing  systems. 

The  DAS /DDPM  is  programmed  in  Product  Line  Simulation 
(PLS)  470/v6  computer  and  is  used  interactively  through  Time 
Sharing  Options  (TSO)  via  a  HP2648A  intelligent  graphics  terminal. 
A  version  of  the  system  is  being  developed  by  Hughes  for  ESD/MITRE 
under  the  name  of  AISIM  (Automated  Interactive  Simulation  Model) . 

Additionally,  another  version  of  the  system  is  being  proposed  to 

3 

RADC  to  support  their  C  analysis  needs.  Both  activities  involve 
translating  the  software  from  PLS  to  SIMSCRIPT  II. 5.  Thus  the 
system  is  accessible  for  those  parties  wishing  to  purchase  the 
capability.  A  detailed  discussion  of  the  system  is  presented  in 
the  following  section. 

4.3.2  DESIGN  ANALYSIS  SYSTEM/DISTRIBUTED  DATA  PROCESSING  MODEL 
DESCRIPTION 

Source 

Hughes  Aircraft  Company,  Ground  Systems  Group,  Fullerton, 
California.  DAS/DDPM  is  a  proprietary  product  of  Hughes  Aircraft 
Company . 

Contacts 

Mr.  John  Camp 

Mr.  Robert  Jones 

Reference  Data 

Mr.  R.  Willis  "Overview  of  Hughes'  Design  Analysis 
System  (DAS) " 


Mr.  W.  Austell  "Overview  of  Hughes*  Distributed  Data 
Processing  Model  (DDPM) " 

Note:  This  data  was  received  in  briefing 

form  in  a  technical  interchange  meeting 
held  at  Hughes  in  January  1980. 

Application 

Operations  analysis,  distributed  data  processing  analysis, 
software  design  analysis. 

Description 

The  DAS  is  a  simulation  and  modeling  development  support 
tool.  The  system  is  hosted  on  an  AMDHAL  470/v6  and  is  used 
interactively  through  TSO  via  an  HP2648  intelligent  terminal. 

The  system  is  comprised  of  interactive  editors  for  designer  and 
analyst  interfaces,  a  generalized  simulator  program  and  a  gen¬ 
eralized  data  base  management  system. 

The  DAS  architecture  is  illustrated  in  Figure  10.  The 
system  features  diagramatic  development  of  models  at  the  terminal, 
automatic  translation  of  diagrams  to  simulation  (obviating  the 
need  for  programming  and  debugging)  interactive  variable  editing 
and  on-line  plotting  and  documentation  of  results. 

A  Design  User  Interface  (DUI)  allows  model  designs  to  be 
created  graphically  at  the  terminal  from  a  data  base  of  symbols 
displayed  on  the  terminal.  Interactively  these  symbols  are 
interconnected  in  a  flowchart  manner.  (Depending  upon  the  data  » 
base, the  user  defines  architectures  and/or  processors) .  Figure  11, 
shows  an  example  of  an  operational  process.  The  symbols  on  the 
left  are  a  menu  of  symbols  used  to  prompt  the  user  while 
building  a  process.  The  flowchart  on  the  right  represents  the 
as-built  process.  Inverse  video  forms  are  used  to  prompt  the  user 
in  assigning  the  required  parameter  data  characterizing  the  opera¬ 
tional  characteristics  for  each  block.  See  Figure  12. 

During  model  development,  the  design  information  is 
maintained  in  a  data  base  for  future  access  by  the  Analysis  User 
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Figure  11.  The  DAS  DUI  Supports  Interactive  Development 
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Interface  (AUI)  for  future  updates.  Prior  to  simulation,  the 
data  in  the  data  base  is  automatically  translated  into  an 
executable  form  negating  the  need  for  programming  or  debugging. 

The  AUI  is  used  to  evaluate  the  dynamic  performance  of 
the  model  during  and  after  simulation  execution.  The  General 
Function  Model,  a  discrete  event  table  driven  model  performs 
the  simulation.  During  execution  via  the  AUI,  the  user  has  the 
option  to  interrogate  the  system  for  specific  statistical  data 
and  to  change  selected  parameters .  At  the  end  of  the  run  and 
at  breakpoints  during  the  run,  plots  of  statistical  data  gathered 
during  execution  may  be  obtained.  At  the  end  of  the  run,  plots 
and  tabular  data  are  available.  Up  to  ten  plots  can  be  displayed 
at  once.  Figure  13  shows  types  of  outputs  available  via  the  AUI. 

The  DDPM  is  a  discrete  event  simulation  mode  that 
supports  the  investigation  of  distributed  computer  system  design 
alternatives.  The  system  features  an  architecture  submodel  for 
defining  model  interconnection  and  message  routing  and  a  library 
of  preprogrammed  submodels  of  functions  of  distributed  data 
processing  systems.  The  model  is  programmed  in  PLS  and  is  hosted 
on  an  Amdhal  470/v6  and  is  used  interactively  by  timesharing 
via  an  HP2648A  graphics  terminal. 

The  DDPM  consists  of  an  executive  driver,  support  soft¬ 
ware  consisting  of  a  simulator  report  generator,  analysis  support 
software,  and  the  library  of  submodels.  Together  these  components 
enable  interactive  model  design,  interactive  simulation  and 
interactive  report  generation.  The  DDPM  architecture  is  illustrated 
in  Figure  14. 

Model  designs  are  developed  from  the  library  of  submodels. 
Each  DDPM  submodel  is  a  logical  and  functional  representation  of 
the  data  processing  component  it  is  modeled  to  represent. 

Operational  characteristics  are  provided  by  default  or  uses 
specified.  Currently  existing  submodels  include: 
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•  CPU  Operating  System 

•  Disk 

•  Network  Control  Unit 

•  Time  Re -ion  Multiple  Access  Bus 

•  Unibus 

•  Unibus  Protocol  Definition 

•  Architecture  and  Protocol 

•  Scenario 

•  Software 

•  Data  Base  Management 

•  File  Management/Data  Base 

Examples  of  the  types  of  parameter  inputs  that  characterize 
some  of  the  submodels'  performances  are  shown  in  Table  5. 

The  DDPM  provides  a  variety  of  statistical  reports  and 
summary  data.  They  pertain  to: 

•  Processor  Utilization 

•  Transaction  Statistics 

•  Memory  Utilization 

•  Device  Utilization 

•  Queueing  Statistics 

These  outputs  are  available  in  a  tabular/listing  format. 

Another  aspect  to  the  DAS/DDPM  capability  is  its  ability 
to  interface  with  a  requirements  data  base.  The  system  has  the 
ability  to  generate  a  requirements  data  base  directly  readable  by 
the  CADSAT  (Computer  Aided  Design  and  Specification  Tool)  system. 
CADSAT  can  product  user  specified  reports  from  this  output. 

Further,  a  version  of  the  DAS/DDPM  is  able  to  read  a  CADSAT 
generated  set  of  requirements  and  build  a  model  from  that  set  of 
requirements . 

Finally,  the  capabilities  of  DAS  and  DDPM  can  be  integrated 
combining  the  best  features  of  each  to  provide  potential  users  a 
fully  interactive  graphics  oriented  distributed  data  processing 
capability. 
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TABLE  5.  EXAMPLE  OF  PARAMETER  INPUTS  TO  THE  DDPM  MODELS 
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System  Attributes 

Performance  -  DAS/DDPM  performance  times  quoted  were  in  the  area 
of  1:15.  That  is,  it  takes  one  second  of  CPU  time 
to  execute  15  seconds  of  simulated  time.  This  is 
possible  principally  because  of  the  speed  of  the 
host  machine  AMDAHL  470/v6  (the  AMDAHL  is  approximate¬ 
ly  four  times  as  fast  as  its  IBM  look-alike) . 

Simulation  Capacity  -  Simulation  capacity  was  cited  in  terms  of 

model  size  of  node.  The  system  has  the  capacity  to 
accommodate  models  of  one-hundred  nodes  without 
overflowing  data  structures  or  requeueing  auxiliary 
storage. 

Ease  of  Use  -  A  judgement  regarding  ease  of  use  would  be  specu¬ 
lative  since  neither  DAS  or  DDPM,  are  adequately 
documented.  However,  the  use  of  interactive 
graphics  and  other  methods  used  to  aid  and  prompt 
the  user  in  the  use  of  these  models  implies  that 
they  are  user  oriented  and  easy  to  use. 

Input  Language  -  DDPM, inputs  are  tabular,  whereas  the  DAS  inputs 

are  more  sophisticated,  using  Operational  Functional 
Diagrams  (OFD)  and  inverse  video  forms  to  prompt 
the  user  for  parameter  values.  Both  methods  are 
cumbersome,  however,  and  the  user  will  require 
familiarity  with  the  input  formats  in  order  to  use 
the  system. 

Flexibility  -  At  the  system  level  the  DAS  has  the  flexibility  to 
support  three  types  of  analysis:  Operational  design 
analysis,  data  processing  design  analysis,  and  soft¬ 
ware  design  analysis.  There  are  no  provisions  for 
selecting  various  levels  of  simulations. 

Diagnostic  -  System  diagnostics  are  poor.  User  must  be  well 

versed  in  all  aspects  of  running  either  DAS  or  DDPM. 

1 
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Output  and  Reports  -  Statistical  output  and  reports  are  available 
in  tabular  form  or  in  plots  at  the  terminal.  The 
user  has  the  option  to  establish  breakpoints  in  a 
simulation  to  interrogate  the  system  for  tabular  or 
plots  of  selected  data.  Up  to  ten  plots  may  be 
displayed  on  the  terminal  at  once.  A  DAS/DDPM 
statistical  output  is  shown  in  Table  6. 

Accessibility  -  Neither  system  (DAS  or  DDPM) is  compatible  with 

local  AFWAL  computer  services .  HAC  has  hosted  the 
systems  on  AMD HAL  470 's  and  in  particular  programmed 
the  DDPM  in  a  proprietary  language.  On  the  other 
hand,  HAC  is  involved  in  contracted  efforts  that 
require  translation  to  rehost  the  system  on  an 
HIS6820  for  RADC  (proposed)  and  an  IBM  370  for 
ESD/MITRE.  The  programs  are  being  translated  to 
SIMSCRIPT  II. 5.  Thus  the  capability  to  adapt  the 
capability  to  other  computing  environments  is 
available. 

Documentation  -  There  is  no  documentation  that  adequately 

describes  or  guides  one  on  the  use  of  DAS  or  DDPM. 
Thus  the  system  is  currently  run  in-house  by 
experts.  The  MITRE  and  RADC  efforts  contracted  for 
documentation . 
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SECTION  V 


SUMMARY  AND  RECOMMENDATIONS 

5 . 0  SUMMARY 

SASC  has  identified  and  described  in  a  preliminary  manner 
three  (3)  simulation  and  modeling  systems  with  potential  AFWAL/ 
AAAS  applicability:  GCSS,  DSDS,  and  DAS/DDPM .  As  a  minimum, 
each  system  is  all-software,  operational  and  models  distributed 
systems.  It  was  also  found  that  AFWAL' s  interest  in  fostering 
its  in-house  modeling  capability  is  shared  by  other  Air  Force 
agencies.  These  agencies  are  currently  performing  what  appears 
to  be  the  next  logical  step  for  AFWAL  in  its  pursuit  of  a  simula¬ 
tion  and  modeling  capability  (i.e.,  detailed  evaluation  and 
acquisition) . 

5.1  RATING  FACTORS 

GCSS,  DSDS,  and  DAS/DDPM  each  present  different  strengths 
and  weaknesses  when  evaluated  by  the  study  criteria.  This  is 
shown  in  Table  7,  which  contains  rankings  for  these  systems. 

Table  7  is  organized  to  present  the  rating  factors  by  groups  in 
order  of  importance.  Accessibility  is  first,  since  a  system  not 
accessible  is  unacceptable,  even  if  technically  excellent. 
Applicability  ranks  second  only  to  accessibility  since  it 
determines  if  a  system  meets  the  criteria.  Ease  of  use  and 
documentation  then  follow,  as  they  only  are  important  considera¬ 
tions  for  systems  ranked  acceptable  by  the  preceeding  two  groups. 
Performance  is  the  last  group  of  factors  since  performance  only 
is  a  consideration  for  systems  which  are  otherwise  acceptable. 
Thus,  as  Table  7  shows,  GCSS  is  the  only  system  readily  access¬ 
ible  to  AFWAL,  and  since  it  is  technically  acceptable,  GCSS 
becomes  the  system  of  choice. 

While  GCSS  is  not  outstanding  in  its  performance  of  any 
requirement,  it  is  a  competent  system  presenting  no  problems  for 
AFWAL.  DSDS  is  a  better  system  than  GCSS,  and  it  is  the  only 
system  having  adequate  documentation.  However,  it  is  run  in  a 
batch  mode  on  a  dedicated  IBM  370,  and  is  implemented  in  an 
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interactive  mode  on  a  Prime  400.  Thus,  it  is  not  hosted  on  a 
computer  available  to  AFWAL,  and  cannot  be  recommended.  DAS/DDPM 
is  by  far  the  fastest  system,  but  it  also  is  implemented  on  a 
computer  not  available  to  AFWAL.  Additionally,  it  is  a  proprietary 
product  written  in  a  proprietary  language,  further  diminishing 
its  attractiveness. 

5.2  RECOMMENDATIONS 

None  of  the  systems  individually  meet  all  of  the  desired 
operational  characteristics  and  requirements.  Therefore,  the 
following  recommendation  is  presented.  This  will  provide  an 
interim  near-term  capability  while  concurrently  defining  AFWAL' s 
ultimate  long-term  needs.  A  three-step  approach  is  recommended: 

1)  GCSS  Implementation  -  Since  GCSS  is  government 
property  and  accessible  via  the  ARPANET,  if  offers 
a  near  term  and  low  cost  means  for  meeting  AFWAL' s 
immediate  needs.  To  implement  the  system  will 
require  obtaining  the  necessary  authorizations  to 
access  the  NADC  CDC  6600  support  from  NADC 
personnel  to  learn  the  interactive  system  and  the 
necessary  hardware  to  accomplish  the  interface. 

2)  Generate  Requirements  -  The  purpose  of  this 
activity  is  to  define  specific  AFWAL/AAAS  simula¬ 
tion  and  modeling  needs  and  requirements.  It  is 
recommended  that  a  definitive  set  of  requirements 
based  upon  current  state-of-the-art  techniques 
and  long-term  AFWAL  goals  be  derived.  This  will 
provide  AFWAL  a  baseline  from  which  it  can  accurately 
assess  the  candidate  systems  in  terms  of  specific 
requirements . 

3)  Detailed  Evaluation  and  Assessment  -  Here  it  is 
recommended  that  AFWAL  review  and  assess  the 
capability  of  the  three  candidate  systems  (GCSS, 

DSDS,  and  DAS/DDPM)  to  meet  the  requirements 
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specified  in  (2) ,  and  determine  the  feasibility 
and  scope  of  modifying  each  system  to  meet  the 
requirements.  Trade  off  the  results  against 
developing  a  new  system  to  meet  the  requirements. 

4)  In  parallel  with  1)  ,  2) ,  and  3) ,  conduct  a  dialog 
with  RADC  and  ESD/MITRE  to  determine  if  there 
are  functions  and  capabilities  that  are  being 
acquired  by  these  agencies  that  could  be  shared 
to  the  mutual  benefit  of  all. 


i 


TABLE  7.  RATING  FACTORS  FOR  GCSS,  DSDS,  AND  DAS/DDPM 

GCSS  DSDS  DAS/DDPM 


ACCESSIBILITY 

* 

0 

- 

Language 

+ 

+ 

- 

(proprietary) 

Host  Computer/Portability 

+ 

- 

- 

Operational  Status 

+ 

+ 

+ 

All  Software 

+ 

+ 

+ 

Availability 

* 

+ 

- 

(proprietary) 

APPLICABILITY 

+ 

+ 

+ 

Avionics  Applications 

+ 

+ 

+ 

Distributed  Processing 

+ 

+ 

+ 

Information  Transfer 

+ 

+ 

+ 

Fault  Tolerance 

+ 

+ 

- 

Time  Division  Multiplex 

+ 

+ 

- 

EASE  OF  USE 

0 

+ 

0 

Set-Up 

+ 

0 

0 

Input  Language 

- 

0 

0 

Diagnostics 

0 

0 

- 

Flexibility 

+ 

+ 

+ 

Outputs  &  Reports 

+ 

+ 

+ 

DOCUMENTATION 

0 

+ 

- 

Systems  Specifications 

0 

+ 

- 

Interface  Descriptions 

- 

- 

- 

User's  Guide 

+ 

* 

- 

PERFORMANCE 

+ 

+ 

* 

Tcpu/Ts 

0 

+ 

* 

Validity 

+ 

+ 

+ 

Capacity 

+ 

+ 

+ 

*  =  The  system  exceeds  AFWAL 

needs 

for  this 

capability. 

+  =  The  system  meets  AFWAL  needs  for  this  capability. 

0  =  The  system  minimally  satisfies  AFWAL  needs  for  this  capability. 
-  =  The  system  does  not  satisfy  AFWAL  needs  for  this  capability. 
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SECTION  VI 


COMPENDIUM 


The  following  lists  the  simulations  that,  during  the 
course  of  the  survey,  exhibited  the  most  potential  to  meet 
AFWAL's  needs.  Included  in  the  list  are  those  simulations 
that  survived  the  screening  as  well  as  those  that  were  dropped 
from  consideration.  Each  entry  is  given  in  a  quick  reference 
format  with  source,  contact,  and  a  brief  description.  An  asterisk 
next  to  the  title  indicates  the  systems  that  were  discussed  in 
Section  IV. 

Title 

VANS  -  Value  Added  Network  Simulator 
Source 

University  of  Minnesota,  Computer  Sciences  Department, 

Minneapolis,  Minnesota 
Contact 

Dr.  G.  Michael  Schneider 
Description 

VANS  is  a  system  designed  to  investigate  the  performance  of 
communications  networks,  message  traffic  handling  and  protocols. 

It  is  hosted  on  a  CDC  6600  and  written  in  PASCAL  and  SIMULA.  The 
system  was  not  designed  to  handle  large  networks.  Thus  its  data 
structures  overflowed  when  models  size  exceeded  twenty  nodes  or 
more.  The  system  was  not  documented  nor  could  support  from  the 
designer  be  obtained.  This,  along  with  the  system's  inability 
to  handle  large  models,  resulted  in  dropping  the  system  from 
consideration . 

Title 

ARES  -  Automated  Requirements  Engineering  System 
Source 

Martin  Marietta  Aerospace  Company,  Denver,  Colorado 


Contact 


Mr.  Richard  E.  Wachs 
Description 

ARES  is  a  discrete  event  simulation  that  models  operating  systems, 
data  base  management,  applications  processing  and  man-machine 
interactions.  ARES  was  one  of  the  four  systems  that  was  included 
in  the  ESD/MITRE  evaluation.  The  system  is  hosted  on  a  CDC  6500 
and  a  DEC  11/70.  It  is  written  in  PASCAL.  ARES  was  not  retained 
principally  because  of  its  current  status.  The  system  was  not 
completely  designed  nor  was  user  or  descriptive  documentation 
completed. 

Title 

PERCAM  -  Performance  and  Configuration  Analysis  Methodology 
Source 

TRW,  Inc.,  Defense  and  Space  Systems  Group,  McLean,  Virginia 
Contact 

Mr.  D.  L.  DeHaven 
Description 

PERCAM  is  a  discrete  event  simulation  that  simulates  network  data 
flows.  The  system  is  used  primarily  in  assessing  combat  effective¬ 
ness  by  the  Army  in  war-gaming.  The  system  is  basically  a  modeling 
tool  that  facilitates  model  development.  The  system  is  hosted  on 
a  CDC  6600  and  is  programmed  in  FORTRAN.  It  was  dropped  from 
consideration  primarily  because  of  the  absence  of  basic  functions 
required  for  the  avionics  functions  and  the  anticipated  effort 
that  would  be  required  to  adapt  it  to  this  environment.  PERCAM 
was  also  one  of  the  systems  included  in  the  ESD/MITRE  evaluation. 
Title 

*GCSS  -  Generalized  Computer  System  Simulator 
Source 

Naval  Air  Development  Center,  Warminster,  Pennsylvania 
Contact 

C.  Mattes,  W.  Garrison 
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Description 

GCSS  is  a  government  owned  all-software  simulation  designed  to 
evaluate  alternate  computer  and  system  architectures  and  bussing 
arrangements.  It  is  hosted  on  the  CDC  6600  computer  and  is 
written  in  SNOBOL  and  SIMSCRIPT  1.5.  GCSS  will  be  used  to 
investigate  architecture  alternatives  and  signal  processing 
requirements  for  the  V/STOL  avionics  system. 

Title 

*DSDS  -  Data  System  Dynamic  Simulator 
Source 

NASA/Marshall  Space  Flight  Center  (MSFC) ,  General  Electric 

Company  (GEC) ,  Huntsville,  Alabama 

Contact 

John  R.  Piner,  NASA/MSFC ;  Norman  F.  Geer,  GEC 
Description 

DSDS  is  a  government  owned  all-software  simulation  designed  to 
perform  comprehensive  design  analysis  and  trade  studies  of  large 
data  processing  and  communication  systems.  The  batch  version  is 
hosted  on  the  IBM  360/75  and  the  interactive  version  is  hosted  on 
PRIME  400.  DSDS  is  written  in  FORTRAN  with  a  modified  version  of 
GASP  IV  for  control  logic.  The  basic  concept  of  DSDS  is  the 
library  of  models  that  can  be  interconnected  to  form  a  network 
configuration  for  evaluation  and  analysis. 

Title 

*DAS/DDPM  -  Design  Analysis  System/Distributed  Data  Processing 

Model 

Source 

Hughes  Aircraft  Company,  Ground  Systems  Group,  Fullerton, 

California 

Contact 

Mr.  John  Camp;  Mr.  Robert  Jones 
Description 

DAS/DDPM  is  a  proprietary  simulation  and  modeling  system  used  to 
analyze  distributed  data  processing  design  alternatives.  The 
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system  is  hosted  on  an  AMDHAL  4  70/V6  and  is  used  interactively. 
The  system  is  programmed  in  a  Hughes  proprietary  language  -  PLS 
(Product  Line  Simulation) .  DAS/DDPM  is  one  of  the  four  systems 
included  in  the  ESD/MITRE  evaluation. 


REFERENCES 


The  following  lists  citations  of  documents  pertaining  to 
simulation  and  modeling  that  were  reviewed  ,  in  search  of  relevant 
systems.  Each  entry  is  presented  by  title,  sponsor/author,  source 
and  date. 


1.  "Installation  Validation  and  Support  of  the  Generalized 
Computer  System  Simulator,  Final  Users  Manual", 

Contract  No.  N62269-77-C-0179  (Sponsored  by  NADC, 

Warminster,  PA.),  Honeywell  Aerospace  and  Defense  Group 
April  19,  1978 

2.  "Installation  Validation  and  Support  of  the  Generalized 
Computer  System  Simulator,  GCSS  Source  Programs, 

Contract  No.  N62269-77-C-0179  (Sponsored  by  NADC, 

Warminster,  PA.),  Honeywell  Aerospace  and  Defense  Group 
April  7,  1978 

3.  "DAS:  An  Automated  System  to  Support  Design  Analysis"  and 
"Design  Evaluation  of  Distributed  Data  Bases  and  Data  Base 
Management",  Willis,  R.  R. ,  Hughes  Aircraft  Company, 

Ground  Systems  Group,  Fullerton,  California,  January  1980 

4.  "Spacelab  Simulation,  DSDS,  SL-1  Model  Implementation 
Report",  Contract  No.  NAS8-31532  (Sponsored  by  NASA/MSFC) , 
General  Electric  Company,  Huntsville  Operations  of  the 
Space  Division,  Huntsville,  Alabama,  March  1979 

5.  "study  to  Establish  Models  and  Simulations  for  Data  Systems, 
Volume  2,  Users  Manual",  Contract  No.  NA8-31532  (Sponsored 
by  NASA/MSFC) ,  General  Electric  Company,  Space  Division, 
Huntsville,  Alabama,  May  17,  1976 

6.  "Data  System  Dynamic  Simulator  Training  Manual",  General 
Electric  Company,.  Space  Division,  Huntsville,  Alabama, 

Sep t embe  r  1978 

7.  "Simulation  Analysis  Report,  Communications  Network  Design 
Problem",  Contract  No.  NAS8-32983  (Sponsored  by  NASA/MSFC 

and  USAF/ESD) ,  General  Electric  Company,  Huntsville  Operations 
of  the  Space  Division,  Huntsville,  Alabama,  October  1979 

8.  "Air  Defense  System- Performance  Analysis  Final  Report, 

Volume  3,  PERCAM  Users  Manual",  Contract  No.  DAA40-77-C-0006 
(Sponsored  by  U.S.  Army  Missile  Research  and  Development 
Command,  Redstone  Arsenal,  Alabama),  TRW  Inc.,  Defense  and 
Space  Systems  Group,  Huntsville,  Alabama,  December  30,  1977 
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9.  Exerpts  from  the  "ARES  Users  Guide",  Wachs,  R.  E.,  Martin 
Marietta  Aerospace,  Denver,  Colorado,  January  1980 

10.  "Evaluation  of  General  Purpose  Modeling  Systems",  Contract 
No.  F19628-80-C-0001  (Sponsored  by  USAF/ESD) ,  Shultze  H.P., 
MITRE  Corporation,  Bedford,  Massachusetts,  February  1980 
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